Mam wrażenie, że problem z uwierzytelnianiem został zaadresowany w #996 . Czego brakuje Ci w #996?

W #996 mamy fejkowego oautha, natomiast nie pozwala nam to pracować z zewnętrznym serwerem developerskim dev.small-eod.siecobywatelska.pl (o ile wstanie :P). Plus dodanie opcji przeskoczenia na basic auth pozwoli nam na szybką zmianę pomiędzy użytkownikami i ich permissionami. Jeszcze jednym plusem jest możliowść pracy na jednym koncie na devie, zamiast ustawiać konto per developer. Ale tak po prawdzie głównie nie zauważyłem dodania fejkowego serwera OAuth,

@rwakulszowa możesz podzielić się opinią?

@MichalKarol, publiczne środowisko dev już działa w oparciu klasyczną infrastrukturę Stowarzyszenia. Uprzejmie proszę o uwagi.

Cóż, dodanie fake oauth to mała zmiana, więc jeśli to rozwiązanie załatwia więcej problemów, to - jak dla mnie - możemy fake oauth szybko wycofać.

O ile dobrze rozumiem, rozwiązanie zaproponowane tutaj sprowadza się do podania danych logowania przy budowaniu projektu - tj. użytkownik albo jest zalogowany, albo nie, przez czas działania aplikacji. To może być problemem przy testowaniu #955. Mamy też trochę utrudnione testowanie całego flow autoryzacji (tj. wylogowany -> zalogowany -> refresh ..).

Głównym powodem dla którego dodałem fake-oauth był fakt, że prawdziwy OAuth jest trudny / niemożliwy do wywołania z localhost. Priorytetem było łatwe postawienie całej aplikacji przez docker-compose up.
O ile rozumiem (nie używałem dev.small-eod, więc mogę się mylić), na środowisku developerskim mamy skonfigurowane Google OAuth i można go używać. Przy dodawaniu fake-oauth raczej zakładałem, że na dev chcemy mieć środowisko jak najbliższe produkcji, a zmiany powinny być ograniczone tylko do aplikacji na localhost.

TLDR: sam skłaniałbym się raczej w stronę fake-oauth, bo wydaje mi się, że logika oparta na flagach podanych ze zmiennych środowiskowych wygląda mniej podejrzanie przy backendzie, ale nie jest to jakaś silna preferencja. Dopóki zaproponowane rozwiązanie pozwoli na łatwe testowanie na localhost, jest mi w zasadzie obojętne co będzie się działo pod spodem.

@MichalKarol czy rozwiązanie z fake-oauth rozwiązuje twój przypadek?

Zamykam PR jako że faktycznie wprowadza zmiany które nie są potrzebne z racji posiadania fake-oauth lokalnie. Natomiast widzę @ad-m że na dev jest jakiś błąd konfiguracji, bo dostaję:

Błąd 401: invalid_client
The OAuth client was not found.